Processes in an application being executed may share resources. Such resources may include objects. For example, different threads in a multithreaded program may share information stored in some critical sections. Accessing shared resources may be mutually exclusive. That is, at a single time, an object can be accessed by only one process. To ensure exclusivity, use of shared objects may be synchronized. Some programming systems provide synchronization libraries. Other programming systems such as Java and C++ offer synchronization capabilities that are built into the programming languages themselves.
In a programming system that has synchronization capabilities built into the language itself, every object may have two fields. One field is a vtable pointer pointing to a shared vtable that stores common information among different objects of a same class. The other field is called lock information that describes the lock status of the underlying object.
FIG. 1 illustrates the construct of objects and their relationship with the shared vtable. There are k objects (e.g., object 1110, object 2120, . . . , object k 130) of a same class. Each of the objects has a pointer to a shared vtable 140 (e.g., pointer to vtable 110a of the object 1110, pointer to vtable 120a of the object 2120, . . . , and pointer to vtable 130a of the object k 130) that stores information common to all k objects in the same class. Each object also has a lock information field (e.g., lock information 110b of the object 1110, lock information 120b of the object 120, . . . , and lock information 130b of the object k 130) that records the lock status of the underlying object.
An object is either locked or not locked. When most objects of a same class are not locked, which is often the case, the lock information within such non-locking objects is identical. Having a separate field in each object to represent the same information wastes memory space and sacrifices efficiency.